Confirming Delivery

I'm a bit confused over the delivery confirmation part of vending systems. It's been a big problem with both in-world and web based systems. People often claim that they did not receive an item that was sent to them through theses systems. This becomes a potential for abuse with no-copy items. Individuals who often reach their IM cap often have this problem if the expect to receive items when they are offline.The only evidence that a seller has is sales logs. A sales log does not confirm the receipt of an item, only that delivery was attempted. This is a large part of why I have primarily sold copyable items only in the past. I can confirm that people purchased a copyable item, so it shouldn't make a difference if I hand them another copy.The nature of the methods available in the scripting language provide the reason why this is such a problem. The simple fact is, that there are not any events or transaction identifiers that we can catch onto. !

Futhermore, inventory that is sent through scripted objects does not show up in our accounts transaction logs either.A simple solution would be to setup llGiveInventory to return a transaction id. This ID could then be reported to my backend database to store. An additional event, "transaction(key transaction_id, integer status)" could let me know if the recipient accepted, denied or muted the inventory, as well as if it was stored since the end-user was offline. Since the transaction_id would come with the transaction, I could then make a call to my backend database to find a match and update the status of the delivery.This solution would solve the problems of abusing the system - specifically with no copy items, since we would be able to confirm that someone did in fact, receive an item in-world.I have some suspitions that this is why the Lindens had recently updated their transaction logs!

format to use UUID's instead of integers for transaction identifiers. What I really love is that you are not constrained if you had more than 500 transactions in a single day, because now they let you also search within a specific time of day. They also cleanded up the XML lots, so that "normal" systems can read it. Just look, it's perfect xml! 6a4b16bf-5094-494c-9c60-f02390a208fc Stipend Base 500 2010-01-12 08:57:37 SYSTEM 1902 Looking at JIRA, I can already see several issues reported on this topic. Go ahead and vote on any that you feel would be useful. [SVC-71] Provide a confirmation mechanism for inventory delivery (e.g. llGiveInventoryWithConfirmation)[SVC-946] llGiveInventory() with feedback[SVC-2224] llGive* feedback and transaction event.The current work-around for such problems, from what I have understood, is a licensing system that keeps track of the number of rezzed items in-world. Such a system would need to verify that you only have as many operational items in-world that you have paid for. Any new ones are crippled.Licensing is something that I'm trying out with my trial license server. At the moment, it is locked on a seven day period from the first day that you rez the object the first time, and allows you to rez as many as you like. After seven days, none of the objects will work - for you. You can hand it off to your fri!

ends and it will work for them if they haven't already gone t!

hrough their own trial period.There are many different types of licenses. Besides trials, there are counts, and perhaps even a site-wide license, in which you can permit people to use as many objects as they like, but they all have to be on a specific region. Another license could be setup so that the owner of the land that it is on must be a specific person (or group). Another license could be purchased for groups, so that the object only works if the group is set on the object, no matter who in the group rezzes it, and/or again, the land itself is owned by the same group. How about a weekly, monthly, or annual license?Licenses can be customized in many different ways. Offering a combination between different types (owner, region, parcel owner, group, count, subsciption) could further meet someones needs. With licensing, you no long need to worry about people finding ways to duplicate your no-copy objects, or rezzing too many at once. However, it!

only works for interactive gadgets.Throwing a licensing script in a bunch of trees no only wastes sim resources, but also don't make much sense. The owner of the land could make sure that scripts are not permitted to run, or use a unique method of rezzing them with an alt that does not have permission to run scripts, where as group members and the owner can.So Licensing only gives a partial solution to the problem. It's hard to verify otherwise that someone is honest in their claims. From Dedric Mauriac via bloghud.com